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(54) Compact disc recording system and method 

(57) An improved file system (55) and method for 
incrementally recording data on compact discs (20) is 
disclosed. The Improved file system (55) and method 
employs compact discs (20) physically formatted in ac- 
cordance with the so-called Orange Book specificatbn. 
Files to be stored are selected from time to time and are 
divided into pacl^ets. The packets are then recorded in 
a program area of the compact disc (20) together with 
link, run-in and run-out blocks in a format compatible 
with the Orange Book rules for linking incrementally re- 
corded packets. File linking informatbn is also stored 



with each file. If desired, files may, but need not, be re- 
corded in a form compatible with existing CD-ROM and 
drivers adhering to the iSO-9660 standard. As selected 
files are recorded, file and directory information are 
stored in a first storage area either in a host system or 
in a track of the compact disc in a double linked and 
highly efficient format. From time to time, and if desired, 
this infonnation may be recorded in ISO 9660 format in 
a resented first track of a session. This may occur upon 
ck>sing the session, at some other time, or not at all. 
Multiple sesskxis may be recorded on the same com- 
pact disc (20). 
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Description 

The invention relates generally to the recording of 
data on compact discs, and, more particularly, to an im- 
proved file system for incremental recording of data onto 
compact discs. 

Since the introduction of the first compact disc play- 
ers in about 1 983, compact disc technology has taken 
the consumer electronics and computer industries by 
storm. What was once a little known technology used 
primarily to reproduce high fidelity audio information for 
the listening pleasure of a fortunate few has become a 
widely used medium for the storage and delivery of a 
variety of different types of infomiatton to a large number 
of individuals and for a wide variety of applications. To- 
day for example, everything from computer programs 
and games to audio programs to video and multi-media 
programs are distributed on compact disc. 

However, while the use of compact discs as a 
means for distributing a wide variety of digital infonma- 
tion sources to end users has advanced considerably, 
the relative unavailability of compact disc recording 
technology, coupled with certain technical limitations 
thereof have, until recently, kept compact disc technol- 
ogy from becoming a viable mass storage alternative for 
most end users, and particularly users of personal conn- 
puters. In the past, compact disc recording devices (CD- 
R's) were very expensive, making them unavailable as 
a practical matter to most personal computer users. Re- 
cently, however, prices have declined to the level where 
many users of personal computers can now easily afford 
to include a CD-R as part of their systems. 

Availability, however, is only part of the problem. 
While the arrival of relatively inexpensive CD-R technol- 
ogy is a welcome advance, its ultimate usefulness to 
personal computer users rennatns significantly limited by 
certain problems and limitatk>ns described hereinafter. 

Over the years, technical specrficatbns and stand- 
ards have been adopted for both the physical layout of 
data recorded on compact discs and for the logical for- 
mat and organizatbn of the data. The great majority of 
manufacturers of compact discs, disc players, arKi disc 
recorders have adopted the physical layout standarcte 
defined in the so-calied Red (also known as lEC 908), 
Yeltow (also known as ISO/IEC 10149), and Orknge 
books produced by Sony and Philips, which are incor- 
porated herein by reference. The logical file stnicture 
whk^h has become the industry standard is the so-called 
ISO 9660 standard, which has been widely published 
and which is also incorporated herein by reference. It is 
estimated that today there is an installed base of more 
than 50 millk>n compact disc players which adhere to 
these industry standards and this installed base contin- 
ues to grow. 

The Yellow and Red Book standards are primarily 
intended to support the recording of a large volume of 
data (up to a capacity of 650 megabytes on a 74 minute 
disc) onto a compact disc in a single, uninterrupted 



write. This works well for publishers and others who use 
CD's, in this case referred to as CD-ROMs, primarily to 
distribute large volumes of data. Most personal compu- 
ter users, however, require the capability to incremen- 

s tally store one or more data files on a mass storage de- 
vice from time to time, and to read these files back at 
other times. While the Orange Book standard provides 
a physical format which supports incremental recording 
of data, a logical file structure that can woric within the 

10 physk:al standard to provide incremental recording ca- 
pability useful to personal computer users is still need- 
ed. 

Under the current standards, a recordable compact 
disc is divided into a fixed number of blocks (also called 
IS sectors). A disc's capacity is measured in terms of min- 
utes, seconds, and sectors. There are 75 sectors in 
each second, so a 74-minute disc, for example, contains 
333,000 sectors, i.e., 74 minutes x 60 seconds/minute 
x 75 sectors/second. The actual amount of user data 
20 that can be recorded in a sector varies with the physical 
format used to record the disc. In the physical format 
nnost comnrKmly used to record computer data, i.e., the 
Yellow Book standard, each sector contains 2 kibbytes 
of data. Thus, in this format a 74-minute disc can contain 
2S up to approximately 650 megabytes of data. 

Under the current Orange Book standard, a disc 
can have multiple sessions. Each session comprises a 
lead-in area, which contains certain control and other 
infomnatbn used by the CD player hardware, a program 
30 area in whbh user data is recorded, and a lead out area. 
A session is cbsed by recording the lead-in and lead- 
out areas after the data to be recorded is recorded in 
the program area. The lead-in and lead-out areas for the 
first sesskxi occupy a total of approximately 23 mega- 
35 bytes of disc storage space. The lead-in and lead-out 
areas for each subsequent sessbn occupy a total of ap- 
proximately 1 3 megabytes of disc storage space. 

Under the current Orange Book and ISO 9660 
standards, data is most often recorded onto compact 
40 disc using the so-called track at once" method. In this 
method, each time data is recorded onto a disc, it is writ- 
ten in consecutive physical sectors in a single track. The 
physical standard Imposes a timtt of 99 tracks per disc, 
which may be distributed between or^e or more ses- 
^ sions. Each track is preceded by a short pre-gap. In or- 
der for recorded files to be read back by existing CD- 
ROM players, an I SO 9660 file structure must be record- 
ed for the data in each track. This file structure may or 
may not describe files which were prevbusly recorded 
50 in other tracks of the same disc. In additkxi, before any 
recorded file can be read, the session containing the 
track in which the file is recorded must be cbsed. 

These existing standarcte present significant limita- 
tions for the personal computer user who wishes to use 
55 CD-R as an incremental mass storage devkie. For ex- 
ample, at any given time a computer user may have only 
one or a small number of relatively snnall files to record, 
periiaps totalling only a few hundred kilobytes. In order 
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to gain access to these files via a current CD-ROM play- 
er, the user would have to close the session containing 
the track in which the files are recorded. Thus, in this 
typical scenario, session overhead of between 13-23 
megabytes is required to gain access to files totaling on- 
ly a few hundred kilobytes. It will be recognized that the 
more often a user repeats this scenario to gain access 
to his data, the more storage space he will lose. More- 
over, an entire ISO 9660 file structure must be re-record- 
ed for each track or set of tracks recorded in each track 
at once write. Thus, if the user desires at some time to 
record a single update to a previously recorded file, tor 
example, a new session must be opened and an entire 
ISO 9660 file structure must be written for the single 
track containing the single updated file. 

A new logk:al file structure specification supporting 
incrementally written files has been proposed by the Eu- 
ropean Computer Manufacturers' Association (EC MA). 
ECMA has proposed a specification, referred to as EC- 
MA 168 (also known as DIS 13490), whk^h Is an exten- 
sion of the I SO 9660 specification. The ECMA 1 68 spec- 
ification is also incorporated herein by reference. 

The Orange Book and ECMA 1 68 specrftcations to- 
gether define a physical recording method and fomr^t 
and a bgical file structure whk:h support incrementally 
recording data onto compact disc in "packets" of fixed 
or variable length. Files written from the host to the CD- 
R to be recorded on the compact disc are divided into 
one or more packets, whk:h are recorded in consecutive 
physical locations, tn order to accommodate the incre- 
mental recording of data at different times, each packet 
is preceded by a link bkx;k and four run-in blocks, and 
folk>wed by two run-out blocks. These add'rtional bkx:ks 
are necessary for the CD-R hardware to determine 
where recording was last interrupted and where record- 
ing can next begin. 

However, the Orange Book/ECMA 168 packet re- 
cording method still has significant limitations. One is 
that it is not compatible with existing CD-ROM players 
and device drivers (or software extenskxis) that adhere 
to certain levels of the Yelbw Book/ISO 9660 specifica- 
tions. Such players and their device drivers do not rec- 
ognize link, run-in and run-out blocks which may be in- 
terspersed with recorded packets. They retum a "read 
error' and abort further playback operation when such 
blocks are encountered. 

CD-ROM designs whk^h recognize and skip over 
the link and run bkxks have been proposed in an effort 
to avoid these "read error" problenns. However, while 
this solution might be feasible when only fixed length 
packets are to be written, it is extremely difficult to im- 
plement when variable length packets of unknown size 
are to be written. Moreover, these changes are incom- 
patible with the huge installed base of existing ISO 9660 
compatible CD-ROM players. These existing players 
will never be capable of reading from compact disc me- 
dia recorded via the packet method as proposed by EC- 
MA. 



Furthermore, the directory, path and tile structures 
proposed by ECMA require extensive amounts of linking 
and re-linking each time a file or directory is updated. 
They are so complex they are generally suitable only for 

5 applicatk^s where only a small number of incremental 
writes are anticipated. Otherwise the structures quickly 
become too complex and unwieldy and require too 
much space and overhead to maintain. 

There thus exists a need for an improved file system 

10 for supporting incremental recording of data onto com- 
pact discs, which overcomes the many heretofore enu- 
merated problems and limitations of the prior art sys- 
tems and methods. The elimination of these problems 
and limitations would finally make CD-R technotogy a 
viable, inexpensive, ultra high capacity, altemative to 
the ever growing mass storage needs of personal com- 
puter users. 

It is therefore one aim of the present inventk>n to 
provide an improved file system and method capable of 

20 supporting the incremental recording of data files onto 
compact disc. 

It is another aim of the present invention to provide 
such a tile system and method that support data files 
incrementally recorded onto compact disc efficiently 

2S and with minimal overhead requirements. 

It is another aim of the present inventk>n to provide 
such a file system ana method capable of providing rap- 
id access to incrementally recorded files. 

It is still another aim of the present inventktn to pro- 

30 vkie such a file system and method which are flexible 
enough to be made conrtpatible with the huge installed 
base of existing CD-ROM players and drivers, and also 
with future CD-ROM player and driver designs. 

It is a further aim of the present invention to provide 

35 such a file system and method which are flexible in im- 
plementation, and which facilitate the recovery of data 
in case of errors or interruptbns. 

It is a still further aim -of the present inventbn to 
provide such a file system and method which will find 

40 use with relatively inexpensive standard CD-Rs which 
may be used with personal computer systems. 

These and other alms, advantages and features of 
the present inventkxi will become clear to those skilled 
in the art by reference to the following summary of the 

45 invention, detailed description of a presently preferred 
embodiment of the inventkxi, and the appended draw- 
ings and claims. 

The present invention substantially ameliorates 
problems and limitations of prk>r art compact disc file 

^ systems and methods by providing a new file system 
and recording method which supports incremental re- 
cording of date files on compact disc while retaining 
compatibility with existing Yeltow Book/ISO 9660 com- 
patible CD-ROM players and drivers, 

^ In the system and method of the present Inventbn. 
one or more files are from time to time selected to be 
stored on a compact disc of the type having a lead-in 
area, a program area and a lead-out area. Selectkxi of 
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the files may encompass creation, e.g., a scanner may 
be the source of a file selected for recording. For each 
file or files selected at a particular time, a determination 
is made of the total storage capacity necessary to store 
the files. A detenminatbn is also made of the availability 
of sufficient storage capacity in the program area of the 
compact disc to store the selected file or files. The files 
are formatted into one or rrtore packets and the packets 
are recorded in the program area of the compact disc 
together with link, run-in and run-out blocks, and link in- 
formation for other recorded packets. Information de- 
scribing each file thus recorded and directory infonma- 
tion are stored in a resented storage location in a host 
system and/or on the compact disc. From time to time, 
the file information for all files previously recorded and 
the directoiy information may be recorded in a reserved 
track of the program area. The file kx^tion and directory 
information thus stored may, rf desired, be made com- 
patible with ISO 9660, ECMA 168 or another logical file 
structure standard at any time, and may ignore any link, 
run-in and run-out bkxks to ensure compatibility with 
existing CD-ROM players and drivers. Multiple sesskjns 
can be created on the same disc by recording a lead- 
out area and repeating the process on a new sectbn of 
the disc with another lead-in, program and lead-out ar- 
ea. 

An embodiment of the invention will now be de- 
scribed in detail, by way of example, with reference to 
the accompanying drawings in which: 

FIG. 1 is a bkxjk diagram illustrating an exemplary 
personal computer system incorporating a pre- 
ferred embodiment of the present invention; 
FIG. 2 is a bkx;k diagram illustrating the functional 
relationship between components of a preferred 
embodiment of the present invention; 
FIG. 3 is a schematic diagram illustrating the Yelbw 
Book physical layout specificatbn for compact 
discs; 

FIG. 4a is a schennatic diagram illustrating the Or- 
ange Book physical layout specification for compact 
discs; 

Fl G. 4b is a schematic diagram illustrating the pack- 
et fonmat used for incremental recording of data in 
the Orange Book specificatkxi; 
FIG. 5 is a schemata diagram illustrating the basic 
ISO 9660 k)gical file/directory structure specifica- 
tion for compact discs; 

FIG. 6 is a schematic diagram illustrating the basic 
ECMA 168 logical file/directory structure specifica- 
tkxi for compact discs; 

FIG. 7 is a schematic diagram illustrating a present- 
ly preferred togical file system format for a compact 
disc for use with the present invention; 
FIG. 8 is a schematic diagram illustrating a present- 
ly preferred packet format for incremental recording 
of files in connectbn with the present inventkxi; 
FIG. 9 is a schematic diagram illustrating a present- 



ly preferred packet format for incremental recording 
of file and directory information in connection with 
the present inventran; 

FIG. 10 is a schemata diagram illustrating a pres- 

5 ently preferred file/directory record format for incre- 
mental recording of file and directory information in 
connection with the present invention; 
FIG. 11 is a schematic diagram illustrating a pres- 
ently preferred format of a SCSI write command for 

10 use with the present invention; 

FIG. 12 is a flow chart illustrating a presently pre- 
ferred mode of operation of the present invention; 
FIG. 1 3 is a flow chart illustrating one presently pre- 
ferred procedure for writing packets to a compact 

IS disc recorder in a presently preferred file system 
embodying the invention; and 
FIG. 14 is a flow chart illustrating a second presently 
preferred procedure for writing data packets to a 
compact disc recorder in a presently preferred file 

20 system embodying the inventton. 

With reference to the drawings, FIG. 1 illustrates an 
exemplary personal cctfnputer system with whk:h a pres- 
ently prefen-ed embodiment of the file system of the 

25 present invention may be used. Computer 1 0 is suitably 
a standard stand-abne personal computer such as an 
IBM™ compatible or Apple Macintosh™ computer, al- 
though a workstatkxi, networked computer, mini-com- 
puter, or other similar informatbn processing devk;e 

^ would also work. As is typical, computer 1 0 has memory 
30 for temporarily holding programs and data, and a 
hard disk 35 for pennanently storing files, which may be 
program, data, application or other files. It is understood 
that although these components are shown in FIG. 1 as 

35 being extemal to computer 10, the figure is merely for 
illustrative purposes and these components will usually 
be intemal. Computer 1 0 may also have connected to it 
via one or more standard serial, parallel, small computer 
system interface (SCSI), or other krK>wn interfaces, a 

40 scanner 25 and^or other peripherals (not shown), such 
as a printer, floppy disk or the like. 

In a presently preferred embodiment of the inven- 
tion, the computer 10 is connected to an Orange Book 
compliant compact disc recorder (CD-R) 1 5 via a stand- 

45 ard SCSI interface. However, it is understood that an 
ATARI or other suitable interface could also be used. 
CD-R's suitable for use with the present invention are 
presently manufactured and sokl by Sony, Rk»h, Yama- 
ha, JVC, PlasnrK>n, Philips, Kodak and others. For ex- 

50 ample, Sony manufactures and sells one such CD-R un- 
der the model designation CDU920S. Philips sells oth- 
ers designated models CDD521 and CDD522. Other 
than as described hereinbebw, the details of construc- 
tion and operation of CD-R 15 is beyond the scope of 

55 this invention and is therefore omitted. 

In a presently preferred embodiment, CD-R 15 op- 
erates with a standard Yeltow and Orange Book compli- 
ant 120mm diameter compact disc (CD) 20. However, 
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it is expressly understood that the invention is not limrted 
with respect to any particutar physical parameters of the 
CD medium. 

Computer 10 may also be connected to a CD-ROM 
player 40 via a standard SCSI, serial or other suitable ^ 
interface. CD-ROM player 40 may be a standard ISO- 
QSeOA'ellow Book compatible player of the type current- 
ly rn wide use, which reads standard 120mm diameter 
ISO-9660A^ellow Book compatible compact discs 45. 
Alternatively, CD-ROM player 40 may be a newer mul- 
tisession type player capable of reading multisession 
CD's as well. It should be understood that the system of 
FIG. 1 is shown with computer 1 0 connected to both CD- 
R 15 and CD-ROM player 40 to facilrtate the description 
of a presently preferred embodiment of the invention, 
wherein CD's recorded by CD-R 15 may be read back 
to computer 10 either by CD-R 15 or CD-ROM player 
40. However, it may well be that in actual practice a CD 
such as CD 20 or 45 is recorded by a CD-R connected 
to one computer, and read back by a CD-ROM player 
connected to another computer. 

As illustrated in FIG. 2, the file system 55 of the 
present invention is preferably interposed between host 
application program 50 and CD-R device driver 60. Host 
application program 50 may be any of a variety of dif- 
ferent programs running in computer 10 that can select 
one or more files to be stored. Such programs may in- 
clude word processing programs such as MicroSoffs 
Word® or WordPerfect Corporation's WordPerfect®, or 
file management programs such as Microsoft® Win- 
dows™ File ^^nager, for example. They may also in- 
clude CD-R specific file back-up progranns written by the 
user or provided by the CD-R manufacturer. 

A presently preferred embodiment of the file system 
55 analyzes and formats the files selected for recording 
by the host application program 50, and creates file and 
directory structures in a manner described in further de- 
tail below. The preferred file system 55 communicates 
the formatted files and file/directory structure informa- 
tion to the compact disc recorder 15 via a conventional 
CD-R driver 60. In a presently preferred embodiment, 
the CD-R device driver 60 communk^ates with the CD- 
R 15 via SCSI commands over a standard SCSI inter- 
face 65, in a manner described in further detail herein- 
after. However, it is understood that other suitable inter- 
faces may be used. 

When files previously recorded on CD-R 15 are to 
be read back, the preferred file system 55 reads and 
interprets the recorded file/directory structures to kx^ate 
the desired files and format them for communicatk>n to 
the host applicatk>n program 50. 

A presently preferred embodiment of the file system 
55 is designed to work with conventk>nal Orange Book 
compliant CD-R's, and to have the capability to record 
compact discs that can be read by existing Yellow Book/ 
ISO 9660 compatible compact disc players using stand- 
ard drivers, such as the conventional Microsoft® MSC- 
DEX driver (or software extension). FIGs. 3, 4a and 4b 



illustrate the conventional physical format specified for 
compact discs such as CD's 20 and 45, by the Yellow 
and Orange Books, respectively. As illustrated in FIG. 
3, the Yelbw Book specificatbn defines a number of ar- 
eas on the physical surface of a write once recordable 
compact disc (CD-WO) 20. Only one half of compact 
disc 20 is shown in FIG. 3. The left side of compact disc 
20 represents the center of the compact disc and the 
right skie the outside edge of the disc. The various areas 
depicted encircle the disc abng an uninterrupted spiral 
track extending substantially from the center of the disc 
to the outside edge. Power Calibration (PCA) 70 and 
Program Memory (PMA) 75 areas are defined to occupy 
adjacent locations nearest the center of the disc. These 
areas are reserved for use by the CD-R hardware. A 
short unrecorded gap 80 separates the PCA and PMA 
areas from a lead-in area (LI A) 65. LI A 85 will contain 
control and mode information, as well as a table of con- 
tents for the tracks recorded on the disc. A correspond- 
ing lead-out area (LOA) 90 is defined to occupy a kxa- 
tion adjacent the outside edge of the disc 20. The area 
between the LIA 85 and LOA 90 is defined to be a pro- 
gram area 95 in which user data is recorded. The pro- 
gram area 95 may be subdivided into a number of tracks 
TNI, TN2 ... TNN, if desired, or may be maintained as 
a single contiguous area. If subdivkJed into tracks, each 
track is preceded by a short pre-gap 1CX). The area in- 
cluding the LIA. LOA and program area comprises a 
sessbn 105. 

Initially, the UA and LOA areas are reserved. Files 
or other data to be recorded are broken into fixed or var- 
iable length blocks. The blocks are then physbally re- 
corded in the program area 95 in consecutive physical 
sectors in one or more tracks, TNI etc. When all the 
data to be recorded has been written to the disc, the 
sessbn may be ck)sed by recording certain control, 
mode and track index informatk>n in the LIA and LOA 
areas. Additk)nal details concerning the parameters and 
contents of the PCA, PMA, LIA, LOA, tracks and pre- 
gap are set forth in the Yellow Book specification and 
need not be repeated here. 

Referring to FIG. 4a, the Orange Book specification 
also defines adjacent PCA 70 and PMA 75 areas near 
the center of the disc. Also similarly to the Yelk>w Book 
specificatkxi, a short gap 80 separates the PCA and 
PMA areas from a first lead-in area UAI 110. Corre- 
sponding with UAI is a first lead-out area LOA1 115. 
The area between UAI and LOA1 comprises a first pro- 
gram area 120. The area comprised of LIA1, the first 
program area 120 and LOA1 comprises a first sessktn 
130. 

A second session 1 35 having a second program ar- 
ea 140, and second lead-in (LIA2) and lead-out (LOA2) 
areas is also illustrated in FIG. 4a. Although only two 
sessbns are shown, as many sessbns may be created 
as desired, up to the storage capacity of the disc. Each 
sessk)n occupies an area adjacent to its immediately 
preceding and succeeding session (if any). 
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Each program area may be subdivided into multiple 
tracks if desired, three such tracks TN1 , TN2, and TN3 
being shown in each of the first program and second 
program areas 1 20 and 1 40. As in the Yelbw Book spec- 
ification, each track is preceded by a short pre-gap 100. 

In order to facilitate the incremental recording of da- 
ta, data is recorded in packets. For example, the data 
recorded In track TNI of the first session 130 couki be 
formatted in three packets PI , P2, and P3. Similarly, the 
data recorded in track TN2 of the first sessk>n 1 30 could 
be formatted In only two packets PI and P2, and so on. 
Each packet 150 consists of a link bkx:k LB, four run-in 
blocks RIB1 -A, a plurality of data blocks DB1 -N, and two 
run-out bkx;ks ROB1-2. The link, run-in and run-out 
blocks enable Orange Book compliant CD-R's to deter- 
mine where a previous record operation ended and the 
next is to begin, and to sync up with the compact disc 
before beginning to record the next packet. Additional 
details concerning packet structure, parameters and 
contents are set forth in the Orange Book speclfbatlon 
and need not be repeated here. 

If the recorded disc is to be readable by existing ISO 
9660 compatible compact disc players using existing 
drivers (or software extensions), such as MSCDEX, ISO 
9660 directory, path and file structures must be recorded 
in the first track, i.e., TNI , of a sessbn. Specific details 
of the ISO 9660 bgk:al directory, path and file structures 
are contained in the published standard and need not 
be set forth in detail here. Generally, however, with ref- 
erence to FIG. 5, the structures include a set of volume 
descriptors 160, which include a primary volume de- 
scriptor (PVD) 170. The PVD contains informatkx) de- 
scribing the data comprising the partrcular volume to 
whk:h the PVD corresponds. The PVD contains flekJs 
175 and 180 for the address and size respectively of a 
path table 1 90. It also includes a copy of a root directory 
record 185. 

Each directory and each file in a directory is de- 
scribed by a file/directory record 200. The root directory 
record 185 in the PVD 170 is a copy of this record for 
the root directory. Each file/directory record 200 in- 
cludes fields 205 and 210 containing the starting block 
address and length respectively of a file or directory en- 
try. Each such record 200 also includes fields 215 and 
225 containing the date and time the file or directory was 
recorded an6 the file or directory name. Each such 
record 200 also contains a flag field 220, whbh includes 
a flag 230 indicating whether the particular record Is for 
a file or a directory entry. Each directory record contains 
a record that identifies its parent directory. File/directory 
records 200 are arranged In alphabetk^l order with 
each directory record being followed by the records for 
each subdirectory and then each file in the directory. 

A path table 1 90 comprises a coilectk>n of directory 
ID records. Each such record Includes fields 235, 240, 
and 245 for the address of a directory record 200, the 
I D # of the parent directory if the directory is a subdirec- 
tory, and the directory name, respectively. The PVD 170 



field 180 points to the address of the first directory ID 
recordof the path table 190. Thus, in the ISO 9660 struc- 
ture a particular file or directory record may be kx:ated 
either by chaining down through the file/directory 
s records 200, or directly via the path table 1 90. 

To retain compatibility with existing ISO 9660 com- 
patible CD-ROM players and drivers, each time an in- 
crenrtental change Is to be recorded, for example a file 
Is to be added, deleted, or changed, or a directory entry 
Is to be added or deleted, the session containing the cur- 
rent ISO 9660 file/directory stnjctures must be closed, 
a new session opened, the update recorded In the new 
sessbn, and the entire ISO 9660 file/directory structure 
rewritten in the new session. This not only takes up a 
significant amount of disc storage for overhead, as de- 
scribed previously. It can also undesirably increase the 
seek time for particular files and directories, especially 
when a number of Incremental changes or additk>ns are 
made. Moreover, many existing versk>ns of Yellow 
Book/ISO-9660 compatible single session CD-ROM 
players remain in use. These players cannot even read 
multi-sesskxi CD's. The present Invention substantially 
overcomes these limitations. 

In addition to the necessity to buikJ and record the 
ISO 9660 file structure in a resen/ed first track of each 
sesskxi, it may also be necessary to adhere to certain 
other conventions to maintain compatibility with CD- 
ROM players and drivers (Including software extensk>ns 
such as MSCDEX) that implement lower levels of the 
ISO 9660 standard. Such players and drivers do not rec- 
ognize link, run-in and run<»ut blocks and return erors 
when they are encountered. CD's incrementally record- 
ed in Orange Book format can nevertheless maintain 
compatibility with such players and drivers If the files re- 
corded are formatted so that each packet contains one 
or more complete files and no file extends across more 
than one packet. If this conventkxi ts folk>wed, then link, 
mnnn and run-out bkx:ks never occur interspersed with 
the data stream comprising the contents of a file. As a 
result, the CD-ROM player's read head never encoun- 
ters these bkx:ks. When a file is to be read, the read 
head is initially addressed to the starting logical bkx:k 
address of the packet containing the beginning of the 
file arrd so does not encounter the link or run-in blocks. 
As the read is completed, the read head encounters an 
end of file (EOF), which terminates the read, before en- 
countering the runout bkx:ks. 

An alternative to the ISO 9660 logk:al file/directory 
structure Is the bgical file/directory structure proposed 
as ECMA 168. This proposed file/directory structure, 
which Is an extension of the ISO 9660 structures, has 
been widely published and need not be repeated here. 
Generally, however, as shown in FIG. 6, the ECMA pro- 
posal includes a volume descriptor set (VDS) 250 sim- 
ilar to the ISO 9660 VDS 1 60. VDS 250 contains one or 
more primary volume descriptors (PVD's) 255. PVD 255 
Is similar to the ISO 9660 PVD 170. One major differ- 
ence is that it does not include a root directory record or 
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any direct pointer to file/directory records. PVD 255 con- 
tains a pointer to a path table 260. which is similar to the 
ISO 9660 path table 1 90. Path table 260 in turn contains 
pointers to a collection of file and directory records 265, 
which are similar to ISO 9660 file/directory records 200. 
Unlikethe I SO 9660 file/directory structure, in the ECMA 
proposal when an incremental change is made to a file 
or directory, it is not necessary to rewrite the entire file/ 
directory structure. In the ECMA 168 proposal, a new 
VDS 270 is created with a new PVD 275. The new PVD 
275 contains a pointer to a new path table 280. The new 
path table 280 contains pointers to the unchanged file/ 
directory records 265 and to any new or updated file/ 
directory records 285. In addition, the new path table 
280 contains a pointer to the previous VDS. The previ- 
ous path table also contains a pointer to any immediate- 
ly previous VDS, and so on. 

It will be appreciated that while the file/directory 
structure proposed by ECMA 168 thus provides inrv- 
proved support over ISO 9660 for incrementally record- 
ed files, the extensive and complex linking involved is 
burdensome and inefficient, especially when a fairly 
large number of incremental changes to files and/or di- 
rectories may be involved. 

The file system of the present inventk)n is capable 
of maintaining compatibility with CD-ROM players and 
drivers at all levels of the ISO 9660 standard. In additk>n, 
the file system of the present invention is flexible enough 
to retain compatibility with future CD-TOM players and 
drivers, which may or may not retain compatibility with 
existing ISO 9660 standards, and even with CD-ROM 
players and drivers that may adopt the proposed ECMA 
166 standard. At the same time, the file system of the 
present invention substantially overcomes the problems 
and limitations of the foregoing logical file/directory 
structure standards. 

Referring to FIG. 7, in a presently preferred form, 
the file system reserves a first track 300 of the program 
area of each session for an ISO 9660, ECMA 168, or 
other file/directory structure. It should be appreciated 
that it is in no way necessary to record any such struc- 
tures in track 300. Rather, track 300 is reserved in the 
event it is desired to record such structures for compat- 
ibility with ISO, ECMA, or another desired standard. As 
will be seen, a presently preferred file system according 
to the inventbn provides complete access to incremen- 
tally recorded files and directories with or without ISO 
and/or ECMA compatibility. 

Foltowing resen/ed first track 300 is a first File In- 
formation Area 305. Fol towing and preferably contigu- 
ous with the first File Information Area 305 is a corre- 
sponding first Data Area 310. Following the first Data 
Area nrtay be a second File lnformatk>n Area 315 and 
Data Area 320, folbwed by addittonal corresponding 
pairs of such areas as desired or as necessary. Each 
File Information Area and each Data Area is preferably 
contiguous with the areas on either side. In a preferred 
embodiment, user file data is recorded in data areas 



310, 320 etc. in a format to be described hereinbetow. 
File and directory structures describing the file and di- 
rectory entries recorded in each data area are recorded 
in the corresponding file infonmation areas 305, 31 5 etc., 
s also in a format described below. 

In a presently preferred embodiment, each file in- 
formation area comprises a reserved track having a pre- 
determined amount of storage space. The amount of 
storage space resented for a file information area de- 
pends upon the applicatkxi. However, for reasons that 
will be made clear betow, a minimum of eight btocks or 
sectors is normally required - a minimum of one btock 
for storage of file and directory structures, and seven 
btocks for link, run-in. and run-out information required 
for Orange Book compliance. 

Each data area also preferably comprises a track. 
However, the anrx>unt of storage space for a data area 
track is not necessarily fixed or predetermined. Rather, 
in a preferred embodiment, files and directory entries 
are recorded in a data area until the data area's corre- 
sponding file information area is full. At that time, the 
data area track is ctosed. A new track is then reserved 
for the next file information area and a new track opened 
for the next data area. Additional files and directory en- 
tries may be recorded in the new open data area track 
until such time as the reserved file information area track 
is again filled, and so on. 

RIes and directory entries recorded in a data area 
are preferably recorded in one or nrwre packets having 
the format shown in FIG. 8. Each packet 325 preferably 
includes at least a packet link header 330, a directory 
fiekl 335, 1 -N file/directory records 340. and one or more 
file data btocks 345 comprising the contents of one or 
more files. 

The packet link header 330 creates a double-linked 
chain t>etween all of the packets 325 recorded in data 
areas. Thus, each packet in a data area is preferably 
linked to the immediately preceding and succeeding 
packets. The first packet in a data area is preferably 
linked to the last packet in the preceding data area, and 
the last packet in a data area is preferably linked to the 
first packet of the succeeding data area. This linked 
chain allows a complete file/directory stmcture to be 
constructed or reconstructed, if necessary, simply by se- 
quentially accessing each packet in the chain. This is a 
significant feature of the present invention, in part be- 
cause it is not necessarily desirable to record the file/ 
directory structures corresponding to a recorded packet 
or set of packets in a file informatton area immediately. 
It will be recalled that each time a set of file/directory 
structures is recorded in the file infonmation area, seven 
additional blocks of link, run-in, and runout infonmatton 
must also be recorded. Accordingly, it is often preferable 
to buffer or cache file/directory infonmatton correspond- 
ing to recorded packets, for example in computer mem- 
ory or on hard disk, until one or nnore blocks of such 
information are accumulated. This preferred approach 
minimizes the amount of storage space in the file infor- 
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mation areas wasted on overhead relative to file/direc- 
tory information. If the cached file/directory information 
should be somehow lost or corrupted before it can be 
recorded, it can be reconstructed from the linked list. 
Moreover, if an interruption or error should occur during 
the packet recording process, it is a straight forward 
matter to determine which packet was last successfully 
recorded and to continue recording with the next linked 
packet by simply chaining down the packets to the last 
one recorded. 

Thus, the packet link header 330 preferably in- 
cludes at least a first field 350 containing the starting 
absolute bkx:k address of the preceding packet and a 
second field 355 containing the starting absolute block 
address of the succeeding packet In additkxi, the pack- 
et link header 330 preferably contains a third fiekJ 360 
containing the number of file and directory entries con- 
tained in the packet. 

The directory fiek) 335 preferably provides tempo- 
rary storage of informatbn required to construct or re- 
construct directory structures when a packet contains 
directory entry informatbn. Thus, this fiekl preferably in- 
cludes at least the directory name, the identity of any 
parent and subdirectories, and a directory identification 
number. 

The file/directory record fieW 340 contains a file/di- 
rectory record for each file contained in the packet and/ 
or for each directory entry, if any. Thus the number of 
file/directory records in field 340 matches the number of 
entries specified in packet link header field 330. 

Each file/directory record preferably has the format 
shown in FIG. 10. In a presently preferred form, each 
file/directory record is a variable length record. The first 
element of the record is preferably a fiekJ 420, whrch 
provides the length of the record. The record may also 
include File Creator 425. File Type 430, and Finder Flag 
435 fields if the inventbn is to be used in conjunction 
with persona! computers manufactured by Apple. These 
fields are used by the Apple Macintosh operating sys- 
tem, for example, to kientify and retrieve files. If not in 
use, these fields may be deleted or set to zero. Prefer- 
ably a field 440 is provided for the file date and time. 
The file date and time are suitably in DOS format, for 
example; and comprise the date and time the file was 
created or, if nrtodified, the date and time of the most 
recent riKxiifk^tion. 

FiekJ 445 preferably is an attribute field whch kien- 
tifies certain attributes of the corresponding file or direc- 
tory. The presence or absence of each attribute is pref- 
erably indicated by the state of a corresponding flag bit. 
Numerous different attributes may be used as desired. 
In a presently prefen-ed embodiment of the inventk>n, 
however, at least the following attribute flags are used. 
Attribute flag 450 indicates whether a file or directory is 
read only or read/write. Attribute flag 455 indicates 
whether a file or directory is hidden. Attribute flag 460 
indicates whether a file is a system or a user file. At- 
tribute flag 465 indicates whether the packet data cor- 



responding to the current file/directory record is a vol- 
ume label. Attribute flag 470 indbates whether the pack- 
et data corresponding to the current file/directory record 
is a file or a directory entry. Attribute flag 475 indicates 
s an archive file similar to the convention used in DOS. 
Attribute flags 480 and 505, as well as others, may be 
reserved if desired for the later addition of other at- 
tributes. Attribute flag 485 indicates whether the file data 
corresponding to the current file/directory record is con- 
tinued over multiple packets. As described in further de- 
tail hereinbelow, a unique feature of the presently pre- 
ferred embodiment is Its ability to record variable length 
packets, as well as very kxig files comprising a plurality 
of packet write operatk>ns, without Interspersing link, 
run-in and run-out bkx:ks with file data. This unique abil- 
ity alk>ws the present invention to record lengthy files 
efficiently while retaining compatibility with existing CD- 
ROM players and drivers implementing level 1 of the 
ISO 9660 standard. Attribute flag 490 indicates the file 
or directory entry corresponding to the current file/direc- 
tory record has been deleted. Attribute flag 495 indi- 
cates the file corresponding to the current file/directory 
record has been moved to another directory. Attribute 
flag 500 indicates that the file corresponding to the cur- 
rent file/directory record is an updated version of an ear- 
lier recorded file. 

Following the attributes fieki 445 is preferably a 
compression type field 51 0, whk:h indicates whether the 
packet data corresponding to the current file/directory 
record is compressed, an6 rf so, the type of compressk>n 
used. Fields 51 5 and 520 preferably contain the uncom- 
pressed and compressed lengths of the file correspond- 
ing to the current record. Field 525 preferably contains 
the starting absolute sector address for the correspond- 
ing file or directory. Field 5^ preferably contains a nu- 
meric volume or sessbn ID indicating the volume or ses- 
sion in which the corresponding file or directory is re- 
corded. Fiek) 535 preferably contains a numeric ID for 
the file or directory corresponding to the file/directory 
record, and fieki 540 preferably contains a numerb ID 
for the parent directory of the file or directory corre- 
sponding to the current file/directory record. FieM 545 
preferably contains the length of the name of the corre- 
sponding file or directory and fiek) 550 preferably con- 
tains the character name of the file or directory. Field 
555 is preferably reserved. 

Similarly to the file and directory entry data recorded 
in the data areas, the file/directory description data re- 
corded in the file informatkwi areas is preferably record- 
ed in packet form in a double linked list. Each packet in 
a file inf omnatk)n area is thus linked to the preceding and 
succeeding packets. The last packet in a file information 
area is preferably linked to the first packet in the next 
file information area and vk:e versa. This format allows 
the file system to rapidly and efficiently traverse incre- 
mentally recorded file and directory structures and to 
minimize the seek time necessary to locate and access 
files and directories recorded in one or more data area 
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tracks. 

FIG. 9 illustrates a presently preferred packet for- 
mat for the file information area data. Each packet 370 
preferably has as a first fiekJ a packet link header 375. 
whrch is essentially identical in format to the packet link s 
header 330 illustrated in FIG. B, and the purpose of 
which, as described, is also the same as packet link 
header 330. The packet link header 375 contains the 
starting absolute block addresses for each preceding 
and succeeding packet in the same file information area, 
except for the first and last packets. The packet link 
header 375 of the first packet preferably contains the 
starting bkx:k address of the last packet in the previous 
file information area, if any, and the packet link header 
of the last packet preferably contains the starting block 
address of the first packet of the next file informatbn 
area, if any. The packet 370 preferably also ccxitains a 
directory structure field 380 and a fieki 385, which con- 
tains complete copies of the file/directory records 1-N 
for each file and/or directory entry contained in corre- 
sponding packets recorded in the corresponding data 
area 

The directory structure field 380 preferably contains 
a subset of the inf ormatbn contained in the file/directory 
record field 385. The subset of infonmatbn is preferably 
selected to enable the file system to rapidly determine 
the relationship between directories, subdirectories and 
files. This ability alk5ws the file system to quickly order 
files and directories in response to directory list com- 
mands and the like, and to rapidly access files and di- 
rectories without having to chain through the file/direc- 
tory records. Thus, only the base informafion necessary 
to locate and order the directories and files is included, 
and other information conceming the contents of files, 
for example whether compressed or uncompressed, is 
excluded. Each directory, subdirectory and file is pref- 
erably assigned a unique ID number based on its order 
in the directory chain. For example, the root directory is 
assigned ID No. 1. the first subdirectory under the root 
directory is assigned ID ^k>. 2. the last subdirectory is 
assigned ID Nto. N, the first file under the directory is 
assigned ID No. N+1 , and so on. Within each directory, 
all subdirectories are assigned consecutive I D numbers, 
folk>wed by all files. Similarly, within each subdirectory, 
sub-subdirectories are consecutively numbered, fol- 
bwed by files. 

The directory structure fieki 380 contains an entry 
388 for each parent directory, preferably sorted by par- 
ent directory ID number. Thus, each entry preferably in- 
cludes as a first subfiekJ 390 a parent directory ID 
number. The next subfiekJ 395 preferably contains the 
number of entries in the parent directory, i.e., the 
number of subdirectories and files. The next subfiekJ 
400 preferably contains the file/directory ID number of 
the first file or subdirectory in the parent directory. The 
next subfield 405 preferably contains the ofiset address 
within the packet 370 for the complete file/directory 
record for the file or subdirectory entry identified in sub- 



fiekJ 400. The next subfield 410 preferably contains a 
copy of the attribute fiekJ for that file or subdirectory en- 
try. The attribute flags can be used to determine the en- 
tries to include in a directory listing or for other purposes. 
For example, by reference to various flags in the at- 
tribute field it can be determined whether a file has been 
deleted, updated or moved. As a result, that file may be 
deleted from a directory listing or listed in another direc- 
tory, for example. Reference to the attribute field may 
also be useful if it is desired to list all previous versions 
of a file which has been updated, for example. Subfields 
400, 405 and 410 are repeated for each subdirectory 
and file in the parent directory. 

Having described the presently preferred logical da- 
ta and file/directory structures whk;h comprise an impor- 
tant part of applrcanrs new and unique file system, at- 
tention will now be turned to describing a presently pre- 
ferred mode of operation, with reference to FIGs. 11-14. 
Referring first to FIG. 12, in order to record one or more 
selected files, the file system 55 first calculates in step 
575 the total storage capacity that will be required to 
record the selected files. In this step, the file system ac- 
cumulates the sizes of the files in bytes, for example 
from their respective directory infonmation on hard disk 
35. It shoukJ be noted that the preferred file system op- 
erates equally well with compressed or uncompressed 
files. In additkxi. based on the packet size being used, 
the file system takes into account the amount of storage 
that will be required for overhead, such as link, run-in 
and run-out bkx;ks required for Orange Book compli- 
ance, packet linking, etc. 

Next, in step 580, the file system determines wheth- 
er the CD to be recorded has prevbusly been initialized. 
The file system issues a SCSI command to the CD-R to 
read the PMA. If the disc has previously been initialized, 
the PMA will contain inforn^ation showing track one as 
resented in the current sessk>n. If the disc has been pre- 
vk>usty initialized, the file system proceeds to the next 
step. If the disc has not been initialized, then in step 582. 
the file system initializes the disc by resenting a first 
track of the current session for the ISO or ECMA file/ 
directory structure area 300, a second track for the first 
file information area 305. and a third open track for the 
fi rst data area 31 0. The file system then proceeds to step 
585. 

In step 585, the file system determines the available 
rennaining storage capacity of the CD to be recorded, i. 
e., the remaining storage capacity of the current data 
area. This is preferably accomplished by issuing a 
standard SCSI READ CAPACITY command to the CD- 
R 15. which retums the next available recordable ad- 
dress and remaining recordable capacity. In step 595. 
the file system compares the available capacity of the 
CD with the required capacity, taking into account the 
need to resen^e sufficient storage on the disc to record 
the required lead-out area If sufficient capacity does not 
exist on the CD to store all of the selected files, the file 
system may initiate any of several suitable actions in 
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step 605. For example, the file system may initiate a suit- 
able error message and abort the operation. 
Altemativety. the file system may initiate a message to 
the user to deselect files, to substitute a CD having the 
necessary available capacity, or to compress the files if 
they are not already compressed. 

If the CD has sufficient capacity, in step 615 the file 
system packetizes the files to be recorded. In this step, 
the files are divided into data blocks, according to the 
standard Orange Book block sizes, to be Included In the 
data bbck fields 345 of one or more packets, a proce- 
dure which is well known. If compatibility with level 1 1SO 
9660 CD-ROM players and drivers is desired, the files 
are divided so that each packet contains one or more 
complete files and no file spans two or more packets. In 
addltk>n, if ISO ^60 compatibility Is desired, the files 
wilt be blocked so that each begins on a block, i.e., sec- 
tor boundary. However, these are not necessary re- 
quirements of the file system of the present invention, 
which readily accommodates flies spanning one or more 
packets, and which can operate quite well without ISO 
9660 compatibility. The size of the packets may be either 
fixed or variable, as desired. Again the file system of the 
present invention readily accommodates either. If the 
packet size is fixed, known optimization techniques may 
be used to minimize the number of packets necessary 
given the sizes of the files to be recorded. Insofar as 
determining packet size is concemed, there are a 
number of factors that may be taken into conskJeratkxi, 
including the size of the host's output buffer, the sizes 
and numbers of the files to be recorded, and the size of 
the CD-R input buffer. Packet sizes may be varied de- 
pending on these and other factors to maximize the 
speed and efficiency of the recording process. Often, 
however, a packet size equal to the size of the CD-Rs 
buffer is desirable so as not to introduce the potential 
for buffer under-run errors. 

Also in step 615, the file system constructs the 
packet link headers 330. directory ftekis 335 and file/ 
directory record fiekJs 340 for each packet. In construct- 
ing the packets, the file system krK>ws the number of 
data bUxkB assigned to each, the number and sizes of 
the file/directory records, etc., and hence the total size 
of each packet. Taking the size of each packet into ac- 
count, the known next recordable address from the CD- 
R, the Orange Book requirements, and the known pack- 
et format, it is straight forward matter for the file system 
to determine the preceding and next packet addresses 
for inclusion in the packet link header field 375. For ex- 
ample, the starting address of the first packet is simply 
the next recordable address plus the required link and 
run-in blocks. The starting address of the next packet is 
the starting address of the current packet plus the pack- 
et size, plus the required run-out blocks. The starting 
address of each succeeding packet may be determined 
in the same manner. For each succeeding packet, the 
starting address of the preceding packet has already 
been determined and therefore may simply be inserted 



in field 350. 

In case of an error during the writing of packets to 
the CD-R, the file system preferably uses the link infor- 
mation to recover. For example, the file system may de- 
s termine the starting address of the last recorded data 
packet by reading down the chain of recorded packets 
until the last completely recorded packet is identified. 
Writing may then be restarted from that point. Alterna- 
tively, the file system couki include in field 330 a special 
signature code, for example in a subfield 357. Then, 
starting with the next recordable address, the file system 
could read back bbck by bkx:k until this signature is rec- 
ognized, indicating the last recorded packet. 

The directory field information and the file/directory 
records may be filled in from directory information and 
file attributes contained on the hard disk 35, for example, 
of the host computer system 10 for the selected files 
and/or directories. This may be supplemented or re- 
placed as desired by allowing the user to provide addi- 
tional or replacement information for the selected file or 
files. Other information in the file/directory records 340, 
such as the starting sector address of the file or directory 
entry, are calculated by the file system starting from the 
next recordable address and taking into account the link 
and run-in blocks, as well as the bkx;ks required for the 
packet link header 330, directory fiekJ 335, and file/di- 
rectory records 340. as well as the order and sizes of 
the files within the data bkx;k field 345 of each packet. 

In step 625, the file system performs similar calcu- 
lations to construct the file informatk>n area packet or 
packets 370 containing the file/directory structures for 
the files/directory entries to be recorded. The file system 
cateulates the starting address of each packet, and each 
preceding and next packet for the packet link header 
378 starting with the next recordable address in the re- 
sented information track obtained from the CD-R and 
proceeding in the same manner as described above. 
The file directory records 385 are simply copied from the 
file/directory records 340 from the corresponding data 
area packet(s). For the directory structure fieki 380, the 
file system assigns the directory and file ID numbers for 
each parent directory, subdirectory and file based on 
their existing relatk>nships. as determined, for example, 
from the directory of hard disk 35 of host computer 10, 
or as supplied by the user. The offset address fieki 405 
for each file/directory record in the packet is determined 
by the file/directory ID number and the total size of the 
file/directory records preceding the partcular record. 
The attribute field 41 0 is copied from the attribute fiekJ 
from the corresponding file/directory record. 

After the file system completes building the file data 
packets to be recorded in the current data area, and the 
file/directory structure packets to be recorded in the cur- 
rent file informatk)n area, in step 635 it sequentially 
writes the file data packets to the CD-R. Either or both 
of two presently preferred write procedures illustrated in 
FIGs. 13 and 14 may be used depending on whether 
fixed or variable packets are used and on the size of the 
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files to be written. 

Each of the packet writing procedures preferably 
employs a standard SCSI WRITE command, an exam- 
ple of which is shown in FIG. 11 . It should be noted that 
while the exemplary SCSI WRITE command shown In 
FIG. 11 is in the common 6 byte fomiat. the equally well 
known 10 byte format could also be used. In additon, it 
will be noted that in the exemplary command, high order 
bits 7 and 6 of control byte 5 are used to designate a 
packet mode code. The SCSI standard reserves these 
bits for vendor use and they are used in the present in- 
vention to implement the unique feature of the invention 
whereby lengthy files may be written to the CD-R in a 
number of packets with a number of WRITE commands, 
while retaining the recoided form of a single packet, if 
desired, for ISO 9660 compatibility. 

Thus, packet nrKxJe 00 designates the standard SC- 
SI write command in which the CD-R is instmcted to 
record a complete packet, framed by link, run-in and run- 
out bkx^ks. It should be noted that the file system need 
not do anything with respect to writing link, run-in or run- 
out blocks when a packet is written because the control 
firmware in standard Orange Book compliant CD-R's 
automatically controls the CD-R recording hardware to 
do so. 

Packet mode 01 instructs the CD-R to record a run- 
in block and the first part of a packet wrthout terminating 
with a run-out block. Packet mode 10 instructs the CD- 
R to record the data presented with no ain-in or run-out 
blocks, and packet mode 1 1 instructs the CD-R to record 
the data followed by a run-out block. The use of WRITE 
commands in the sequence of packet mode 01 , 10, and 
1 1 thus albws a lengthy file to be written and to appear 
in recorded form as a single long packet, independent 
of host or CD-R buffer sizes, or other conskJeratwns 
(such as to avokl buffer under-run conditbns). 

No hardware modificatbns are required to a stand- 
ard Orange Book compliant CD-R to implement modes 
01 , 10, and 11 . A simple change to the control firmware 
to recognize these modes and to direct the recording 
hardware when and when not to record link, run-in and 
run-out blocks as described above is all that is required. 
This simple modificatbn is well within the ordinary skill 
of persons engaged in the CD-R arts and a descriptkxi 
thereof is therefore unnecessary for a complete under- 
standing of the invention. 

Referring to FIG. 1 3, in one writing procedure useful 
with fixed, relatively small packets, the file system is- 
sues a SCSI WRITE command in Mode 00 in step 680. 
The SCSI WRITE command contains in bytes 2 and 3 
the starting LBA (bgical block address) at which the first 
packet is to be written, as prevkxjsly cateulated by the 
file system, and the length in bytes of the packet in byte 
4, also as prevk>usly calculated. In step 685, the file sys- 
tem transmits the first packet to the CD-R, which records 
it on the CD, starting at the specified LBA. In step 690 
the file system checks whether another packet renrtains 
to be written. If not, the write process is complete. If an- 



other packet is to be written, the driver issues another 
SCSI command and the process repeats until all pack- 
ets have been written. 

FIG. 14 illustrates a second write procedure whrch 

5 is useful for bng files that exceed the CD-R buffer size, 
or which for other reasons need to be written to the CD- 
R using several packets. In order to maintain compati- 
bility with CD-ROM players and drivers implementing 
level 1 ISO 9660, this procedure causes the CD-R to 

10 record the file as rf it contained within a single packet. 
In this procedure, the file system in step 700 issues a 
SCSI write comnoand in packet mode 01 . The LBA and 
transfer length fields in this command are determined in 
the same manner as described above for the packet 

IS mode 00 command. In step 705, the driver transmits a 
first packet to the CD-R. This causes the CD-R to record 
a link block, four mn-in blocks, and the data contained 
in the packet starting at the specified starting LBA, as 
specified by the Orange Book. However, the CD-R does 

20 not record any run-out blocks. Next, in step 71 0 the file 
system issues another SCSI WRITE command in pack- 
et mode 10 and in step 715 transmits a second packet 
of data to the CD-R. The packet mode 10 WRITE com- 
mand causes the CD-R to record the packet at the spec- 
ks ified starting LBA (whrch it is assumed immediately fol- 
lows the last LBA of the preceding packet)wrthout any 
link, run-in or run-out blocks being recorded. In step 720, 
the file ^stem determines whether any additional con- 
finuatkKi packets remain to be written. If so, the packet 

30 mo6e 10 writing process is repeated until all continua- 
tion packets have been written. When all confinuatbn 
packets have been written, in step 725 the file system 
issues a final SCSI WRITE command in packet mode 
11 . In step 730 it transmits the last packet to the CD-R. 

3S In this writing procedure, it is assumed the last packet 
written wilt always be written in packet nnode 11 so that 
the recorded packet data will be followed by the run-out 
bkx:ks required for Orange Book compatibility. By writ- 
ing in this manner, kxig files that are written to the CD- 

40 R in multiple packets, are thus recorded in the form of 
a single long packet, thus retaining compatibility with the 
ISO 9660 standard. It should be noted that although the 
procedure illustrated in FIG. 14 includes one or more 
continuatk>n packets written in packet nrKxJe 10, the 

^ same p rocedure wouk) work with on ly two packets to be 
written. In that case, the first packet wouki be written in 
packet nrKxje 01 and the second in packet mode 11. 
Packet mode 10 woukJ not be used. 

In the preferred continuation packet write procedure 

50 of FIG. 14, the file system may determine the number 
of continuation packets to be written in any number of 
ways. One way, for example, is to simply divide a large 
file into packets, each being the same size as the CD- 
R's input buffer. If this resulted in ten packets, for exam- 

55 pie, the first packet would be written in packet mode 1 0, 
and the tenth and last packet in packet mode 11 . 

Referring back to FIG. 12, when all of the packets 
containing the selected files have been written to the 
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CD-R and recorded, the file system in step 640 deter- 
mines if there is sufficient room remaining in the current 
file information area to write the packet(s) containing the 
file/directory structures for the files and directory entries 
just recorded, together with any packets containing file/ 
directory structures in cache and not yet recorded. If 
there is sufficient room in the current file information ar- 
ea, the file system attempts to write the current file/di- 
rectory structures into the cache In step 645. In step 650, 
if writing to the cache would cause It to become full, then 
in step 655 the current file structures and those in cache 
are transmitted to the CD-R and recorded in the current 
file information area. The processes described with re- 
spect to FIGs. 1 3 and 1 4 are suitable for writing the file/ 
directory structure packets to the CD-R. 

However, if in step 640, there is insufficient room 
remaining in the current file informatk>n area to accom- 
modate the cache contents and the current file/directory 
structures, then in step 660, the file system writes the 
file/directory structure packets from cache into the file 
information area, maintaining the linking between pack- 
ets as previously described. The file system then closes 
the track for the current data area in step 665, reserves 
a new track for the next file infomiation area in step 670, 
and opens a new data area track in step 675. The file 
system then retums to step 645 and writes the current 
file/directory structure packet(s) into the cache, includ- 
ing the link to the last packet in the previous file infor- 
mation area. That operation completes the recording 
process for the selected file or files. 

As one alternative to the foregoing, the file system 
could make the determinatbn whether to record the file/ 
directory structure packets in the file information area 
based on the status of the cache, but instead on a timed 
basis. In this alternative, the file system would record 
any cache contents in the current file tnformatk)n area 
at predetermined intervals regardless of the state of the 
cache. For example, the file system might be invoked to 
record the cache contents in the file informatk>n area on 
a daily basts. 

From time to time the user may select additional 
files to be recorded. Each time ackJitbnal files are se- 
lected, the process illustrated in FIG. 12 is carried out 
by the file system. 

From time to time the user may also wish to perform 
operatk)ns such as adding or deleting directories, or de- 
leting, moving or updating files. The preferred file sys- 
tem according to the inventkxi supports such opera- 
tkxis. In response to a command to add or delete a di- 
rectory, the file system constructs a data packet to be 
recorded in the current data area and a packet to be 
recorded in the current information area. These packets 
are constructed as illustrated in FIGs. 8-10 and de- 
scribed above, and contain the appropriate attribute 
fields to indicate whether the directory record is being 
added or deleted. Similarly with respect to deleting or 
moving a file, the file system constructs packets to be 
recorded in the data and file information areas according 



to FIGs. 8-10. These packets contain the attribute fields 
indicating the status of the file. In either scenario, the 
file system then writes the packets to the data and file 
infomnatton areas in the same manner as previously de- 

s scribed with respect to FIGs. 1 2-1 4. 

The preferred file system of the inventkffi allows the 
user to read recorded files from a partially or completely 
recorded CD using a standard Orange Book compliant 
CD-R at anytime. Standard SCSI READ commands are 

10 preferably used to read back the recorded packets and 
a substantially reverse process is carried out by the file 
system to de-packetize and reconstruct the recorded 
files and directory information. 

If at any time the user should desire for a partially 

^5 or completely recorded CD to be readable by a CD-fK)M 
player and driver implementing ISO 9660, the user may 
render the disc compatible simply by cbsing the current 
session. In a presently preferred embodiment of the file 
system, when the current session is closed, the file sys- 

20 tem reads the file/directory structures from the fi le infor- 
nnatk>n areas contained in the current sessk)n, and re- 
records the same information in the reserved track one 
of the sesskxi in ISO 9660 compatible format. Alterna- 
tively, the file system could re-record the file/directory 

25 structure information in the first resewed track in ECMA 
168 or another suitable format if desired. Alternatively, 
this process need not be carried out automatically upon 
ck>sing the current session, but could be triggered on 
command from the user, if desired. 

30 If desired, and if sufficient capacity remains on the 
CD after the current session is closed, the user may use 
the file system to open a new sessk>n and the entire 
rtKxie of operation described above may be repeated. 
Although the applicant has described herein a pres- 

ss ently preferred embodiment of the invention, it will be 
apparent to persons skilled in the art that the inventk>n 
is capable of other arKi different embodiments, arKJ that 
the details of the preferred embodiment are capable of 
numerous nrxxiifications without departing from the spirit 

40 of the inventkxi. Accordingly, the drawings and descrip- 
tion are to be regarded as illustrative in nature only, and 
not as limiting the scope of the invention, which is to be 
determined by reference to the appended claims. 

45 

Claims 

1. A method of incrementally storing data on a com- 
pact disc of the type having a lead-in area, a pro- 
so gram area having a plurality of sectors, and a lead- 
out area, characterised by: 

selecting from time to time at least one file to 
be stored; 

S5 each time at least one file is selected, 

determining the total storage capacity nec- 
essary to store all selected files; 
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least one packet includes a variable number of data 
blocks. 

10. The method of any preceding daim wherein said 
s first storage area is in a host computer. 

11. The method of any preceding claim wherein said 
first storage area is on said compact disc, 

^0 12. The method of any preceding claim wherein said 
data area includes a plurality of tracks. 

13. The method of claim 12 wherein said second re- 
sented storage area comprises the first of said plu- 

15 rality of tracks. 

14. The method of claim 12 or claim 13 wherein sakd 
first storage area includes the second of said plu- 
rality of tracks. 

20 

15. The method of any preceding claim wherein the 
method is repeated to create multiple sessions on 
the same compact disc. 

25 16. The method of any preceding claim wherein the 
step of selecting at least one file includes creating 
a file. 

17. A system for incrementally storing data on a com- 
30 pact disc of the type having a lead-in area, a pro- 
gram area having a plurality of sectors, and a lead- 
out area, comprising: 



determining the availability of sufficient 
storage capacity in said program area of 
said compact disc to store each selected 
file; 

dividing each selected file into one or more 
data bkx:ks and creating at least one pack- 
et including at least one said data block; 
recording said at least one packet in said 
program area together with a correspond- 
ing link block, at least one run-in block, at 
least one data bkxk, and at least one run- 
out block; and 

storing in a first storage area information 
kJentifying the kx^ation of each selected file 
in said program area; and 

from time to time recording in a second re- 
served storage area in saki program area infor- 
mation identifying the location of each selected 
file previously recorded in said program area 
ignoring all corresponding link blocks, run-in 
blocks and run-out bkxks. 

2. The method of claim 1 including recording with each 
selected file link information to the recorded kxjation 
of at least one other selected file. 

3. The method of claim 1 or claim 2 wherein the lead- 
in program, and lead-out areas of saki compact disc 
are in a format compatible with the Orange Book 
standard. 

4. The method of any preceding claim wherein said at 
least one packet is recorded in a form compatible 
with the Orange Book specificatton for linking pack- 
ets recorded incrementally. 

5. The method of any preceding claim wherein each 
packet contains at least one complete selected file. 

6. The method of any preceding claim wherein sakJ 
information, stored in said second reserved storage 
area kientifying the location of each selected file 
prevk>usly recorded in saki program area is in ISO- 
9660 compatible format. 

7. The method of any one of claims 1 to 5 wherein said 
information stored in said second reserved storage 
area kientifying the locatkxi of each selected file 
prevk)usly recorded in sakJ program area is in EC- 
MA 1 68 compatible format. 

8. The method of any preceding claim wherein said at 
least one packet is recorded in said program area 
with the beginning of each file starting on a sector 
boundary. 

9. The method of any preceding claim wherein said at 



means for selecting from time to time at least 
35 one file to be stored; 

means for, each time at least one file is select- 
ed. 

determining the total storage capacity nec- 
^ essary to store all selected files; 

determining the availability of sufficient 
storage capacity in saki program area of 
said compact disc to store all selected files; 
and 

^ divkiing each selected file into one or more 

data blocks and constructing at least one 
packet ifK^luding at least one said data 
block; 

50 a compact disc recorder operable to receive 

and to record said at least one packet in the 
program area of said compact disc together 
with a corresponding link bkx:k, at least one 
run-in block and at least one runK>ut bkx:k; 
55 saki compact disc recorder including means to 

store in a first storage area each time said at 
least one selected file is recorded in saki pro- 
gram area, Infomnation identifying the locatk>n 
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of said at least one selected file recorded in said 
program area; and 

said compact disc recorder also including 
means operable to record from time to time in 
a second resented storage area in said pro- 
gram area information identifying the location 
of eacfi selected file previously recorded in said 
program area, ignoring all corresponding link 
blocks, run-in bkx:ks and run-out blocks. 

18. The system of claim 17 including means for record- 
ing with each selected file In said program area link 
information to the recorded location of at least one 
other selected file in said program area. 

19. Ttie system of claim 17 or claim 18 wherein the 
lead-in program, and lead-out areas of said com- 
pact disc are in a format compatible with the Orange 
Book standard. 

20. The system of any one of claims 17 to 1 9 wherein 
said at least one packet are is recorded in a form 
compatible with the Orange Book specification for 
linking packets recorded incrementally. 

21. The system of any one of claims 17 to 20 wherein 
each packet contains at least one complete select- 
ed file. 



29. The system of claim 28 wherein said second re- 
served storage area comprises the first of said plu- 
rality of tracks. 

s 30. The system of claim 28 or claim 29 wherein said 
first storage area comprises the second of said plu- 
rality of tracks. 

31. The system of any one of claims 1 7 to 30 wherein 
10 each collection of files having k>cation Information 
recorded in said second storage area comprises a 
sessbn. said system including means to create 
multiple sessions on the same compact disc. 

'5 32. The system of any one of claims 1 7 to 31 wherein 
said means for selecting at least one file includes 
means for creating a file. 



20 



25 



22. The system of any one of claims 17 to 21 wherein 30 
said Information stored in said second storage area 
identifying the locatk>n of each selected file previ- 
ously recorded in sakJ program area is In ISO-9660 
compatible fomnat. 

35 

23. The system of any one of claims 17 to 21 wherein 
said information stored in said second reserved 
storage area identifying the locatk>n of each select- 
ed file previously recorded in said program area is 

in ECMA 168 compatible fonmat. 40 



24, The system of any one of claims 17 to 23 wherein 
said compact disc recorder is operable to record 
said at least one packet with the beginning of each 
file starting on a sector boundary. 45 



25, The system of any one of claims 17 to 24 wherein 
said at least one packet includes a variable number 
of data blocks. 

26. The system of any one of claims 1 7 to 25 wherein 
said first storage area is In said host system. 



27. The system of any one of claims 1 7 to 26 wherein 
said first storage area is on said compact disc. ss 



28. The system of any one of claims 1 7 to 27 wherein 
said data area includes a plurality of tracks. 
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